Amazon GuardDutyによる疑わしいネットワーク通信の検知と初動対応の振り返り

Amazon GuardDutyは、AWS上の異常な振る舞いを検出するサービスです。 イベントソースには、AWS CloudTrail、Amazon VPC フローログ、DNS ログが使われます。 GuardDutyを使う中でたまった知見をシェアしたいと思います。

GuardDutyで検知できること

検知できる内容はユーザーガイドに記載されています。 ざっくりいうと、EC2インスタンスとIAMアカウント関連のイベントを検知します。

EC2に関するイベントは、EC2がターゲットなのか、アクターなのかによって分けられます。 外部のホストがEC2に対してポートスキャンを行うイベントの場合、EC2はターゲットになります。 外部ホストにポートスキャンを行う場合、EC2はアクターになります。 EC2がアクターの場合、EC2がマルウェアに感染している可能性を考える必要があります。

料金は1ヶ月間無料です。 請求統合を使っている場合でも、無料枠を利用できます。

発生したイベントの通知

GuardDutyはCloudWatch Eventsに通知を送信します。 CloudWatch Eventsから、Amazon SNSを使ってメール通知したり、Lambdaを使ってSlackなどに通知できます。

セキュリティサービスを使う上で過剰に通知される懸念を持たれる方も多いかと思いますが、GuardDutyでは毎日複数のイベントが発生するようなケースは少ないようです。 私の観測範囲では、IAMアカウント関連のイベントが発生しやすいです。詳しくは後述します。 不要な通知が頻発する場合は、CloudWatchイベントのイベントパターンを絞るか、Lambdaで通知するイベントを絞るなどといった対応になるかと思います。

通知されたイベントの処理

イベントの通知を受け取ったら、イベントの内容を確認します。 ユーザーガイドには、イベントの詳細と対応方法が記載されています。 過去に発生したイベントとその対応について、いくつか紹介します。

UnauthorizedAccess:IAMUser/UnusualASNCaller

「UnauthorizedAccess:IAMUser/UnusualASNCaller」はAPIが通常とは異なるIPアドレスから呼び出されると発生します。 普段オフィス利用しているIAMユーザーに、外出先（モバイルルーターなど）でログインすると発生しやすいです。 ラスベガスで開催されるre:Invent参加中にAWSコンソールにログインした時などに検知していました。 リモート勤務が認められている企業では特に発生しやすいかと思います。 私の環境では、外出先からのログインなど心当たりがあったので、問題なしと判断しています。

ユーザーガイドの侵害されたAWS認証情報の修正も参考になります。 問題のあるIAMユーザー、キーなどを削除した上でAWSリソースに変更が発生していないか確認しましょう。 AWS Configを有効化しておくと、リソースの変更履歴を後から追えます。

普段利用しないリージョンにEC2を建てられ、仮想通貨のマイニングに使われるケースが多いです。 検証アカウントのような場合は、AWSアカウントを解約し環境を作り直してもいいかと思います。

Backdoor:EC2/Spambot

「Backdoor:EC2/Spambot」はEC2がリモートホストと25番ポートで通信した時に発生します。 EC2がマルウェアに感染し、スパムメールを送るようなケースを検知できます。 起動してからしばらくたったEC2にメールソフトをインストールし、テストメールを送った際に検知しました。 時間帯に心当たりがあったので問題なしとしました。

Behavior:EC2/NetworkPortUnusual

「Behavior:EC2/NetworkPortUnusual」はEC2が通常と異なるポートでリモートホストと通信した際に発生します。 EC2がマルウェアに感染し通常とは異なるポートで通信している可能性があります。 GuardDutyにはリモートホストのIPアドレスやポート番号などの情報が記録されます。 心当たりのある通信か確認します。

Behavior:EC2/NetworkPortUnusualの初動対応

Behavior:EC2/NetworkPortUnusualが発生し状況を確認したところ、リモートホストのIPアドレスやポート番号に心当たりがない状況に当たりました。 つまり、マルウェアに感染した可能性が出てきました。 手っ取り早いのは、EC2を停止または隔離する対応です。 EC2を停止すればマルウェアの感染が広がるリスクやマルウェアの活動を停止できます。

侵害されたEC2インスタンスの修正に基づき、最新のアンチマルウェアをインストールし、フルスキャンを実施しましたが、検知しませんでした。 アンチマルウェアが検知できないのか、GuardDutyが誤検知したのかなど様々な可能性があり、安心できない状況でした。 また、検知したリモートホストと継続的に通信が行われていないのか気になりました。 単発的な事象なのか、継続的に発生している事象なのか気になったわけです。

そこで、脅威リストを使ってみることにしました。 継続的にリモートホストと通信が発生している場合、脅威リストに登録すればイベントが発生すると考えたためです。 登録の結果、FTPの通信を大量に検知しました。 FTPについて考えたところ、ホストに心当たりがありました。 Behavior:EC2/NetworkPortUnusualが発生した原因として、DNS名に紐づくIPアドレスが変更された可能性や、FTPのパッシブポートがたまたまいつも使われていない範囲で使われたと推測しています。 いずれにせよ、不明なホストではなく、システムと連携しているホストと通信していたことを確認できました。

振り返り

初動対応を振りかえり、今後に活かせないか考えてみました。

VPCフローログの有効化

VPCフローログを有効化しておくべきだと思いました。 VPCフローログを有効化しておけば、「DNS名に紐づくIPアドレスが変更された可能性や、FTPのパッシブポートがたまたまいつも使われていない範囲で使われた」という推測を確認できたと思われます。 VPCフローログの集計はAthenaで行えます。 IAMアカウント関連のイベントに備えて、CloudTrailも有効化しておくと助かるかと思います。

変更監視の有効化

Trend Micro Deep Securityで行えるような変更監視を導入しておくと良いかなと思いました。 変更監視は、OS上のファイルの変更などを監視するものです。

GuardDutyでイベントが発生すると、誤検知なのかどうかを判断する必要があります。 GuardDutyのイベントと同じタイミングで変更監視も検知した場合は、攻撃が成立してしまったという判断ができると思われます。 攻撃を防御するという観点では、アンチウイルスソフトも有効かと思います。 Deep Securityはアンチウイルスソフトの機能も持っているため、改めて良い製品だと感じました。

デプロイ方法の改善

本当にマルウェアに感染していた場合、EC2の停止か作り直しを行う必要があります。 EC2の作り直しはミドルウェアやアプリケーションのセットアップなど骨が折れる作業です。 AWS CodePipelineなどを使った自動デプロイができていれば、EC2の作り直しも比較的簡単にできるかと思います。

まとめ

Amazon GuardDutyの知見について、共有しました。 GuardDutyはEC2やIAMに関する不審なアクティビティを通知してくれます。 GuardDuty自体は優秀なサービスだと感じています。ぜひ、全リージョンでの有効化をご検討ください。 VPCフローログ、CloudTrail、AWS Configなどを有効化しておくと、イベント発生時の判断に使えるかと思います。合わせて有効化すると良いでしょう。